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Abstract 


For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) 
signaling, in certain cases a combination of <link identifier, label> 
is not sufficient to unambiguously identify the appropriate resource 
used by a Label Switched Path (LSP). Such cases are handled by using 
the link bundling construct, which is described in this document. 
This document updates the interface identification TLVs, which are 
defined in the GMPLS Signaling Functional Description. 
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1. Introduction 


For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) 
signaling, in certain cases a combination of <link identifier, label> 
is not sufficient to unambiguously identify the appropriate resource 
used by a Label Switched Path (LSP). Such cases are handled by using 
the link bundling construct, which is described in this document. 
This document updates the interface identification TLVs, which are 
defined in the GMPLS Signaling Functional Description. 


1.1. Specification of Requirements 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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Link Bundling 


As defined in [GMPLS-ROUTING], a traffic engineering (TE) link is a 
logical construct that represents a way to group/map information 
about certain physical resources (and their properties) that 
interconnect LSRs with information that is used by Constrained SPF 
(for the purpose of path computation) and by GMPLS signaling. 


As stated in [GMPLS-ROUTING], depending on the nature of resources 
that form a particular TE link for the purpose of GMPLS signaling, in 
some cases a combination of <TE link identifier, label> is sufficient 
to unambiguously identify the appropriate resource used by an LSP. 

In other cases, a combination of <TE link identifier, label> is not 
sufficient. Consider, for example, a TE link between a pair of 
SONET/SDH cross-connects, where this TE link is composed of several 
fibers. In this case the label is a TDM time slot, and moreover, 
this time slot is significant only within a particular fiber. Thus, 
when signaling an LSP over such a TE link, one needs to specify not 
just the identity of the link, but also the identity of a particular 
fiber within that TE link, as well as a particular label (time slot) 
within that fiber. Such cases are handled by using the link bundling 
construct, which is described in this document. 


Consider a TE link such that, for the purpose of GMPLS signaling, a 
combination of <TE link identifier, label> is not sufficient to 
unambiguously identify the appropriate resources used by an LSP. In 
this situation, the link bundling construct assumes that the set of 
resources that form the TE link could be partitioned into disjoint 
subsets, such that (a) the partition is minimal, and (b) within each 
subset, a label is sufficient to unambiguously identify the 
appropriate resources used by an LSP. We refer to such subsets as 
"component links", and to the whole TE link as a "bundled link". 
Furthermore, we restrict the identifiers that can be used to identify 
component links such that they are unique for a given node. Ona 
bundled link, a combination of <component link identifier, label> is 
sufficient to unambiguously identify the appropriate resources used 
by an LSP. 


The partition of resources that form a bundled link into component 
links has to be done consistently at both ends of the bundled link. 
Both ends of the bundled link also have to understand the other end’s 
component link identifiers. 


The purpose of link bundling is to improve routing scalability by 
reducing the amount of information that has to be handled by OSPF 
and/or IS-IS. This reduction is accomplished by performing 
information aggregation/abstraction. As with any other information 
aggregation/abstraction, this results in losing some of the 
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information. To limit the amount of losses, one needs to restrict 
the type of information that can be aggregated/abstracted. 


2.1. Restrictions on Bundling 


All component links in a bundle have the same Link Type (i.e., 
point-to-point or multi-access), the same Traffic Engineering metric, 
the same set of resource classes at each end of the links, and must 
begin and end on the same pair of LSRs. 


A Forwarding Adjacency may be a component link; in fact, a bundle can 
consist of a mix of point-to-point links and FAs. 


If the component links are all multi-access links, the set of IS-IS 
or OSPF routers that are connected to each component link must be the 
same, and the Designated Router for each component link must be the 
same. If these conditions cannot be enforced, multi-access links 
must not be bundled. 


Component link identifiers MUST be unique across both TE and 
component link identifiers on a particular node. This means that 
unnumbered identifiers have a node-wide scope, and that numbered 
identifiers have the same scope as IP addresses. 


2.2. Routing Considerations 
A component link may be either numbered or unnumbered. A bundled 


link may itself be numbered or unnumbered, independent of whether the 
component links of that bundled link are numbered. 


Handling identifiers for unnumbered component links, including the 
case in which a link is formed by a Forwarding Adjacency, follows the 
same rules as those for an unnumbered TE link (see Section "Link 
Identifiers" of [RFC3477]/[RFC3480]). Furthermore, link local 
identifiers for all unnumbered links of a given LSR (whether 
component links, Forwarding Adjacencies, or bundled links) MUST be 
unique in the context of that LSR. 


The "liveness" of the bundled link is determined by the liveness of 
each of the component links within the bundled link; a bundled link 
is alive when at least one of its component links is determined to be 
alive. The liveness of a component link can be determined by any of 
several means: IS-IS or OSPF hellos over the component link, RSVP 
Hello, LMP hellos (see [LMP]), or from layer 1 or layer 2 
indications. 
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Once a bundled link is determined to be alive, it can be advertised 
as a TE link and the TE information can be flooded. If IS-IS/OSPF 
hellos are run over the component links, IS-IS/OSPF flooding can be 
restricted to just one of the component links. Procedures for doing 
this are outside the scope of this document. 


In the future, as new Traffic Engineering parameters are added to 
IS-IS and OSPF, they should be accompanied by descriptions as to how 
they can be bundled, and possible restrictions on bundling. 


2.3. Signaling Considerations 


Because information about the bundled link is flooded, but 
information about the component links is not, typically, an LSP’s ERO 
will identify the bundled link to be used for the LSP, but not the 
component link. While Discovery of component link identities to be 
used in an ERO is outside the scope of the document, it is envisioned 
that such information may be provided via configuration or via future 
RRO extensions. When the bundled link is identified in an ERO or is 
dynamically identified, the choice of the component link for the LSP 
is a local matter between the two LSRs at each end of the bundled 
link. 


Signaling must identify both the component link and label to use. 
The choice of the component link to use is always made by the sender 
of the Path/REQUEST message. If an LSP is bidirectional [RFC3471], 
the sender chooses a component link in each direction. The handling 
of labels is not modified by this document. 


Component link identifiers are carried in RSVP messages, as described 
in section 8 of [RFC3473]. Component link identifiers are carried in 
CR-LDP messages, as described in section 8 of [RFC3473]. Additional 
processing related to unnumbered links is described in the 
"Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV", 
and "Unnumbered Forwarding Adjacencies" sections of 
[RFC3477]/[RFC3480]. 


[RFC3471] defines the Interface Identification type-length-value 
(TLV) types. This document specifies that the TLV types 1, 2, and 3 
SHOULD be used to indicate component links in IF_ID RSVP_HOP objects 
and IF_ID TLVs. 

Type 1 TLVs are used for IPv4 numbered component link identifiers. 


Type 2 TLVs are used for IPv6 numbered component link identifiers. 


Type 3 TLVs are used for unnumbered component link identifiers. 
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The Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used. 
Note, in Path and REQUEST messages, link identifiers MUST be 
specified from the sender’s perspective. 


Except in the special case noted below, for a unidirectional LSP, 
only a single TLV SHOULD be used in an IF_ID RSVP_HOP object or IF_ID 
TLV. This TLV indicates the component link identifier of the 
downstream data channel on which label allocation must be done. 


Except in the special case noted below, for a bidirectional LSP, only 
one or two TLVs SHOULD be used in an IF_ID RSVP_HOP object or IF_ID 
TLV. The first TLV always indicates the component link identifier of 
the downstream data channel on which label allocation must be done. 
When present, the second TLV always indicates the component link 
identifier of the upstream data channel on which label allocation 
must be done. When only one TLV is present, it indicates the 
component link identifier for both downstream and upstream data 
channels. 


In the special case where the same label is to be valid across all 
component links, two TLVs SHOULD be used in an IF_ID RSVP_HOP object 
or IF_ID TLV. The first TLV indicates the TE link identifier of the 
bundle on which label allocation must be done. The second TLV 
indicates a bundle scope label. For TLV types 1 and 2, this is done 
by using the special bit value of all ones (1) (e.g., OXFFFFFFFF for 
a type 1 TLV). Per [RFC3471], for TLV types 3, 4, and 5, this is 
done by setting the Interface ID field to the special value 
OxFFFFFFFF. Note that this special case applies to both 
unidirectional and bidirectional LSPs. 


Although it SHOULD NOT be used, when used, the type 5 TLV MUST NOT be 
the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV. 


2.3.1. Interface Identification TLV Format 


This section modifies section 9.1.1. of [RFC3471]. The definition of 
the IP Address field of the TLV types 3, 4, and 5 is clarified. 


For types 3, 4, and 5, the Value field has an identical format to 
the contents of the C-Type 1 LSP_TUNNEL_INTERFACE_ID object 
defined in [RFC3477]. Note that this results in the renaming of 
the IP Address field defined in [RFC3471]. 
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2.3.2. Errored Component Identification 


When Interface Identification TLVs are used, the TLVs are also used 
to indicate the specific components associated with an error. For 
RSVP, this means that any received TLVs SHOULD be copied into the 
IF_ID ERROR_SPEC object (see Section 8.2 in [RFC3473]). The Error 
Node Address field of the object SHOULD indicate the TE Link 
associated with the error. For CR-LDP, this means that any received 
TLVs SHOULD be copied into the IF_ID Status TLV (see Section 8.2 in 
[RFC3472]). The HOP Address field of the TLV SHOULD indicate the TE 
Link associated with the error. 


3. Traffic Engineering Parameters for Bundled Links 


In this section, we define the Traffic Engineering parameters to be 
advertised for a bundled link, based on the configuration of the 
component links and of the bundled link. The definition of these 
parameters for component links was undertaken in [RFC3784] and 
[RFC3630]; we use the terminology from [RFC3630]. 


3.1. OSPF Link Type 


The Link Type of a bundled link is the (unique) Link Type of the 
component links. Note that this parameter is not present in IS-IS. 


3.2. OSPF Link ID 


For point-to-point links, the Link ID of a bundled link is the 
(unique) Router ID of the neighbor. For multi-access links, this is 
the interface address of the (unique) Designated Router. Note that 
this parameter is not present in IS-IS. 


3.3. Local and Remote Interface IP Address 
Note that in IS-IS, the Local Interface IP Address is known as the 


IPv4 Interface Address and the Remote Interface IP Address is known 
as the IPv4 Neighbor Address. 


If the bundled link is numbered, the Local Interface IP Address is 
the local address of the bundled link; similarly, the Remote 
Interface IP Address is the remote address of the bundled link. 
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3.4. Local and Remote Identifiers 


If the bundled link is unnumbered, the link local identifier is set 
to the identifier chosen for the bundle by the advertising LSR. The 
link remote identifier is set to the identifier chosen by the 
neighboring LSR for the reverse link corresponding to this bundle, if 
known; otherwise, this is set to 0. 


3.5. Traffic Engineering Metric 


The Traffic Engineering Metric for a bundled link is that of the 
component links. 


3.6. Maximum Bandwidth 


This parameter is not used. The maximum LSP Bandwidth (as described 
below) replaces the Maximum Bandwidth for bundled links. 


3.7. Maximum Reservable Bandwidth 


For a given bundled link, we assume that either each of its component 
links is configured with the Maximum Reservable Bandwidth, or the 
bundled link is configured with the Maximum Reservable Bandwidth. In 
the former case, the Maximum Reservable Bandwidth of the bundled link 
is set to the sum of the Maximum Reservable Bandwidths of all 
component links associated with the bundled link. 


3.8. Unreserved Bandwidth 


The unreserved bandwidth of a bundled link at priority p is the sum 
of the unreserved bandwidths at priority p of all the component links 
associated with the bundled link. 


3.9. Resource Classes (Administrative Groups) 


The Resource Classes for a bundled link are the same as those of the 
component links. 


3.10. Maximum LSP Bandwidth 


The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. 
For an unbundled link, the Maximum Bandwidth is defined in 
[GMPLS—-ROUTING]. The Maximum LSP Bandwidth of a bundled link at 
priority p is defined to be the maximum of the Maximum LSP Bandwidth 
at priority p of all of its component links. 
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The details of how Maximum LSP Bandwidth is carried in IS-IS is given 
in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth is carried 
in OSPF is given in [GMPLS-OSPF]. 


4. Bandwidth Accounting 


The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an 
LSR with bundled links must apply admission control on a per- 
component link basis. An LSP with a bandwidth requirement b and 
setup priority p fits in a bundled link if at least one component 
link has a maximum LSP bandwidth >= b at priority p. If there are 
several such links, the implementation will choose which link to use 
for the LSP. 


In order to know the maximum LSP bandwidth (per priority) of each 
component link, the Traffic Control module must track the unreserved 
bandwidth (per priority) for each component link. 


A change in the unreserved bandwidth of a component link results ina 
change in the unreserved bandwidth of the bundled link. It also 
potentially results in a change in the maximum LSP bandwidth of the 
bundle; thus, the maximum LSP bandwidth should be recomputed. 


If one of the component links goes down, the associated bundled link 
remains up and continues to be advertised, provided that at least one 
component link associated with the bundled link is up. The 
unreserved bandwidth of the component link that is down is set to 
zero, and the unreserved bandwidth and maximum LSP bandwidth of the 
bundle must be recomputed. If all the component links associated 
with a given bundled link are down, the bundled link MUST not be 
advertised into OSPF/IS-IS. 


5. Security Considerations 


This document defines ways of utilizing procedures defined in other 
documents, referenced herein. Any security issues related to those 
procedures are addressed in the referenced documents. Thus, this 
document raises no new security issues for RSVP-TE [RFC3209] or CR- 
LDP [RFC3212]. 


6. IANA Considerations 
This document changes the recommended usage of two of the 
Interface_ID Types defined in [RFC3471]. For this reason, the IANA 
registry of GMPLS Signaling Parameters has been updated to read: 


4 T2 COMPONENT_IF_DOWNSTREAM - DEPRECATED 
5 12 COMPONENT_IF_UPSTREAM — DEPRECATED 


Kompella, et al. Standards Track [Page 9] 


RFC 4201 Link Bundling in MPLS-TE October 2005 
7. References 
7.1. Normative References 
[GMPLS-ISIS] Kompella, K. Ed. and Y. Rekhter, Ed., "Intermediate 
System to Intermediate System (IS-IS) Extensions in 
Support of Generalized Multi-Protocol Label Switching 
(GMPLS)", RFC 4205, October 2005. 
[GMPLS-OSPF] Kompella, K. Ed. and Y. Rekhter, Ed., "OSPF 


[GMPLS-ROUTING] 


[RFC3471] 


[RFC3473] 


[RFC3472] 


[RFC3784] 


[RFC3630] 


[RFC3480] 


[RFC3477] 


Kompella, 


et al. 


Extensions in Support of Generalized Multi-Protocol 
Label Switching (GMPLS)", RFC 4203, October 2005. 


Kompella, K., Ed. and Y. Rekhter, Ed., "Routing 
Extensions in Support of Generalized Multi-Protocol 
Label Switching (GMPLS)", RFC 4202, October 2005. 


Berger, L., "Generalized Multi-Protocol Label 
Switching (GMPLS) Signaling Functional Description", 
RFC 3471, January 2003. 


Berger, L., "Generalized Multi-Protocol Label 
Switching (GMPLS) Signaling Resource ReserVation 
Protocol-Traffic Engineering (RSVP-TE) Extensions", 
RFC 3473, January 2003. 


Ashwood-Smith, P. and L. Berger, "Generalized Multi- 
Protocol Label Switching (GMPLS) Signaling 
Constraint-—based Routed Label Distribution Protocol 
(CR-LDP) Extensions", RFC 3472, January 2003. 


Smit, H. and T. Li, "Intermediate System to 
Intermediate System (IS-IS) Extensions for Traffic 
Engineering (TE)", RFC 3784, June 2004. 


Katz, D., Kompella, K., and D. Yeung, "Traffic 
Engineering (TE) Extensions to OSPF Version 2", RFC 
3630, September 2003. 


Kompella, K., Rekhter, Y., and A. Kullberg, 
"Signalling Unnumbered Links in CR-LDP (Constraint-— 
Routing Label Distribution Protocol)", RFC 3480, 
February 2003. 


Kompella, K. and Y. Rekhter, "Signalling Unnumbered 


Links in Resource ReSerVation Protocol - Traffic 
Engineering (RSVP-TE)", RFC 3477, January 2003. 


Standards Track [Page 10] 


RFC 4201 Link Bundling in MPLS-TE October 2005 
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997. 
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 
LSP Tunnels", RFC 3209, December 2001. 
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., 
Wu, L., Doolan, P., Worster, T., Feldman, N., 
Fredette, A., Girish, M., Gray, E., Heinanen, J., 
Kilty, T., and A. Malis, "Constraint-Based LSP Setup 
using LDP", RFC 3212, January 2002. 
TBs Informative References 
[ LMP ] Lang, J., Ed., “Link Management Protocol (LMP)", RFC 


Authors’ Addresses 


4204, October 2005. 


Kireeti Kompella 
Juniper Networks, Inc. 
1194 N. Mathilda Ave. 


Sunnyvale, 


CA 94089 


EMail: kireeti@juniper.net 


Yakov Rekhter 


Juniper Networks, Inc. 
1194 N. Mathilda Ave. 


Sunnyvale, 


CA 94089 


EMail: yakov@juniper.net 


Lou Berger 
Movaz Networks, 


Inc. 


Phone: +1 703-847-1801 
EMail: lberger@movaz.com 


Kompella, et al. 


Standards Track [Page 11] 


RFC 4201 Link Bundling in MPLS-TE October 2005 


Full Copyright Statement 
Copyright (C) The Internet Society (2005). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at ietf- 
ipr@ietf.org. 


Acknowledgement 


Funding for the RFC Editor function is currently provided by the 
Internet Society. 


Kompella, et al. Standards Track [Page 12] 


